In recent years, software developers have become increasingly reliant upon computer aided software engineering (CASE) tools. This is due, at least in part, to increasing consumer demand for software of greater complexity and improved reliability. CASE tools characteristically permit software to be abstracted to a level at which architectures and designs are more apparent than in their source code form, and may thus speed robust development.
In the realm of object oriented (OO) software design, one type of CASE tool that may be of considerable benefit to a software developer is the OO model editor (or simply “model editor”). Model editors, such as the Rational Rose® Unified Modeling Language (UML) model editor, promote improved visualization and comprehensibility of object oriented designs by permitting a developer to view and edit abstract classes for a particular application graphically, for example. Model editors and associated tools, such as the “add-in” extensions to the Rational Rose® model editor, may be capable of automatically generating object oriented programming language (OOPL) code corresponding to a graphically-created model, to facilitate the often tedious task of software implementation.
A related type of software tool is the object editor. Unlike the odel editor, which edits OO models (i.e. abstract classes), an object editor is capable of displaying and editing software objects (i.e. instances of modeled classes). Though not CASE tools, object editors are nevertheless beneficial in that, like model editors, they promote improved visualization and comprehensibility of object oriented entities (for clarity, the term “object editor” herein should be understood to include applications which merely display objects but are not necessarily capable of updating the objects).
An object editor may be implemented in accordance with the Model View Controller (MVC) paradigm. As known by those skilled in the art, the MVC paradigm dictates that an application's representation of “real-world” entities, its user interface, and its manner of mapping the real world entity representations to the user interface shall be handled by way of a separate “Model” component, “View” component, and “Controller” component, respectively. A benefit of adopting the MVC paradigm is modularity and component reusability.
In an MVC compliant object editor, the objects being edited may comprise the “Model” component, as the objects typically represent “real world” entities. A known UI framework, such as the JavaTM Foundation Class Swing components from SUN® Microsystems (“Swing”), may be chosen to comprise the “View” component. A UI framework such as Swing provides the basic UI constructs (e.g. windows, buttons, menus, etc.) for implementing a graphical user interface (GUI) and may advantageously be familiar to the user. A UI framework may further include high level constructs which facilitate such operations as displaying a set of objects in the form of a tree (e.g. the javax.swing.Jtree construct of Swing) or as a table. Finally, the “Controller” component may comprise a UI framework controller module (e.g., in the case of Swing, javax.swing.tree.TreeModel) which is designed to map certain generic methods (e.g. getchildren, getText or the like) to logically analogous methods in application objects to be edited (e.g., for a bank object, getAccount and getBankName, respectively). This mapping facilitates a tree-like or tabular display that is logical with respect to the nature of the displayed objects. As known to those skilled in the art, the UI framework's higher level constructs are segregated from the UI framework controller module for reasons of code efficiency; many of the mapping functions implemented by the controller module may be needed by more than one high level construct (e.g. a tree display construct and a table display construct may both need to invoke a “getText” method for a displayed object).
In certain implementations, the “Controller” component of an MVC compliant object editor may further include an adapter. As known to those skilled in the art, an adapter is a software component (e.g. an object) which converts the interface of one or more classes to an interface expected by a client, which in the instant case is the UI framework controller module. Adapters are described in the text Design Patterns: Elements of Reusable Object Oriented Software by Erich Gamma et al., 1995, Addison Wesley (Chapter 4). In the instant case, the adapter adapts the interface of the objects to be edited (i.e. the “Model”) to the interface expected by the UI framework controller module and thus “adapts” the objects of interest to the UI framework.
Some object editors may be capable of use with objects which incorporate a dynamic reflection capability. As known to those skilled in the art, reflection is the capacity of a software object to have its characteristics determined dynamically through “examination” of the object at run time. In simple terms, reflection permits an object to be dynamically queried as to the attributes that it possesses and its associations with other objects (which may be referred to herein as its “relatives”). Software objects with this capability may be interacted with even in the case where the object's attributes (e.g. fields) and associations with relatives (e.g. children) are not known at the time of implementation.
For example, an object having a dynamic reflection capability (referred to herein as a “reflective” object) which comprises an instantiated OOPL class representative of, say, an automobile, may be interrogated at run time as to its characteristics, and in response may indicate that it has four attributes named “make”, “model”, “color”, and “year” and two associations with other objects, namely an “owner” object and a “dealer” object. Further, this reflective object may provide the current values of these attributes and references to the associated “relative” objects. All of this is possible despite the interrogator's initial lack of awareness that the object under interrogation was in fact representative of an automobile.                An example of objects possessing this dynamic reflection capability is Meta Object Facility (MOF) compliant objects. As known to those skilled in the art, MOF is a standard defined by the Object Management Group (OMG) for managing meta information. MOF is not in itself a programming language, but rather may be implemented in a chosen OOPL (e.g. Java™), in the form of a software component such as a “MOF package” for example, which may be incorporated into objects (e.g. by way of object oriented inheritance) to provide them with MOF capabilities. Objects that are created in this manner are said to be “MOF compliant” and may be referred to simply as MOF objects. The creation of MOF objects may be facilitated by software tools similar to those which create OOPL code from a graphical (e.g. UML) model, which may be used in conjunction with the Rational Rose® Model Editor.        
The dynamic reflection capability of MOF objects is facilitated by MOF's “reflective module”, through which “meta-objects” associated with the MOF objects may be accessed. As known by those skilled in the art, it is these meta-objects that provide the above described object “meta-information” regarding MOF object characteristics (e.g. a “meta-automobile” object can return information regarding the characteristics of a corresponding “automobile” object at run time, as described above).
In the context of the above-described MVC compliant object editor, a benefit which arises when the objects being edited are reflective is that the adapter may in some respects be made more generic. That is, rather than containing specific “hard-coded” references to particular attributes, relationships or methods of an object being edited, the adapter may utilize more generic reflection tools (e.g. in the case of MOF objects, reflective module methods such as refMetaObject, refValue, refSetValue, etc.) to gain access to the attributes and relationships of the object(s) being edited by way of the associated meta-objects.
Disadvantageously, however, the adapter component cannot be made entirely generic. This is because, despite the use of the reflection within the adapter code, at some level (e.g. in the context of parameters to reflective module methods) the adapter still “hard-codes” which application objects, attributes and associations should be accessed to effect the desired “view” of the displayed objects. For example, if it is desired to display an automobile object's “color” attribute in the operative view, the corresponding reflective method invocation within the adapter code is required, at a minimum, to specify the “color” attribute of the automobile object as the attribute name for which a current value reading is required. Disadvantageously, if it is desired to change the way in which objects or attributes are displayed (e.g. which application objects and attributes are visible or the arrangement of object data), or if it becomes necessary to use the editor with a new class of objects with different attributes and associations, the adapter code must be painstakingly updated and then recompiled in order to effect the desired changes. This constraint impacts negatively on the object editor's flexibility.
In applications other than object editors, adapter software components may be used to conform the interface of one or more application object classes to an interface expected by a client. The role served by the adapter in such applications is similar to the aforedescribed role of the adapter in an object editor, with the exception that the client in such cases is not a UI framework but rather some other software component. Here too, adapters suffer from a problem similar to the one described above: if it is desired to change the way in which application objects or attributes are accessed by the adapter, or if it becomes necessary to use the adapter with a new class of objects with different attributes and associations, the adapter code must be edited and then recompiled in order to effect the desired changes.
What is therefore needed is an object editor capable of editing reflective objects which may be configured to selectively display objects and their attributes without necessitating software recompilation. What is also needed is a method of configuring an adapter to selectively access objects including reflective objects and their attributes without necessitating adapter recompilation.